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REMARKS 

Applicant respectfully traverses and requests reconsideration. 

As a preliminary matter, Applicant respectfully requests the Examiner to remove the 
finality of the rejection since it appears that the Office Action introduces a nev^ basis for 
rejection not previously provided in the previous Office Action. For example, with respect to 
Claim 1 and the other claims rejected under 35 U.S.C. § 102(a), the Office Action in the 
"Examiner's Response" section, uses a different basis of rejection. For example, in the previous 
Office Action, the Examiner stated that the claimed "second entity" was the "trigger" in the cited 
reference. Now for the first time, the final Action states that the "website" is the "second 
processing entity." In addition, the "third processing entity" in the previous Office Action was 
alleged to be the java script installation script that let a client device use a client version registry 
to keep track of the software and keep track of versions and locations installed in the computer. 
(Page 4 of original Office Action). 

However, in the final Office Action, the Examiner takes a new position and instead states 
that the third processing entity, is "wherever" the location of the updated software is. Hence, 
Applicant respectfully submits that since these are new reasons for rejection, the finality of the 
rejection should be withdrawn. 

Claims 1-5, 8-10, 12-17, 20-21 and 23-26 stand rejected under 35 U.S.C. §102(a) as 
being anticipated by Netscape's "SmartUpdate Developer's Guide" dated March 11, 1999. The 
"SmartUpdate Developer's Guide" describes fi'om a software developer's perspective, a 
mechanism for distributing and installing software over the internet and over intranets. Java 
Archive Files (JAR files) is an installable file dovraloaded to a user's machine in response to 
JavaScript used to trigger a SmartUpdate installation from a web page. A Client Version 
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Registry is a cross platform registry that records all software installed through SmartUpdate and 
is stored on the user's machine. Content creators can modify their pages to initiate an 
installation through SmartUpdate. Users can securely download or install or update software on 
their machines. 

In the "Examiner's Response," it appears that the Examiner may be misapprehending 
Applicant's claim language. In addition. Applicants have amended the claims to include the 
limitations of originally filed claims such as, for example, Claim 2. In addition, Applicant notes 
with respect to the independent claims that the additional language is inherent language of the 
original claim indicating that Applicant's claimed system, among other things, provides update 
complete data which is different from the updated dated that is updated, such as a software 
program, under control of the third processing entity, for the second processing entity. As such, 
the update complete data that is provided is not the same data as the updated data but to the 
contrary is another piece of data such as a cookie or other suitable information sent by the third 
processing entity by way of the first processing entity to the second processing entity. No such 
update complete data is described as being sent by the alleged second entity of the reference. It 
appears that the Examiner also admits this in the response. 

The Examiner states that "this limitation just says the third entity provides an update 
complete indication to the second entity. Clearly the second entity knows the update is complete 
(data provided) and is therefore able to provide web access to the first entity (user) ... a rather 
indirect, but still reasonable manner." Thus, the Examiner alleges that the cited reference by the 
fact that a software update is complete, somehow this is equivalent to Applicant's claimed 
invention. Applicant notes that the Examiner uses the words "complete indication." However, 
Applicant claims a different approach. The update complete data sent between the varying 
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entities is different from the updated data that is provided by the third processing entity to the 
first processing entity. Accordingly, this is distinctly different from the reference as admitted by 
the Examiner. As such, the claims are in condition for allowance. For example, as noted in 
Applicant's specification on pages 8 and 9, for example, the third processing entity sends an 
update complete and redirect command back to the first processing entity for detection by the 
second processing entity. The second processing entity is able to detect this because the first 
processing entity effectively resends the update complete data to the second processing entity. 
The update complete data and the redirect command include, for example, a URL of the second 
processing entity along with data representing a third processing entity cookie indicating it has 
been sent to the first processor. The first processor then sends, for example, the URL of the 
second processing entity in a header with the data software cookie that's set equal to "yes" as 
provided by the third processing entity. As such, in one example, the third processing entity 
provides update complete data, such as a cookie, to indicate that the update was complete. This 
cookie is then resent by way of the first entity to the second entity. The second entity analyzes 
this data to determine that the update has been complete. Such an operation is not described or 
suggested in the cited reference. Accordingly, these claims are in condition for allowance. 

As to claim 14, the Office Action rejects this claim for the same reasons given with 
respect to claim 1 . As such. Applicant respectfully reasserts the relevant remarks made above 
and also submits that claim 14 is allowable. Moreover, the Office Action, on page 7, does not 
make clear which element within SmartUpdate is the third processing entity. In any event. 
Applicant also respectfully notes that claim 14 requires other limitations not present in claim L 
For example. Applicant claims detecting the need to update web certificate data for the web 
browser and providing web certificate update complete data as well as sending an universal 
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resource locator associated with a processing entity to a web browser as claimed. The Office 
Action cites page 11, chapter 4, as describing detecting a need to update web certificate data. 
However, this portion merely indicates that signed Java classes may be used which are typically 
digitally signed objects or other information. There is no discussion of web certificates or a need 
to update web certificates as required by the claim. Accordingly, this claim is also believed to be 
in condition for allowance. 

As to claim 2, Applicant respectfiilly submits that this claim is at least allowable 
depending from an allowable base claim. 

As to claim 3, Applicant respectfully notes that this claim requires, among other things, 
providing update confirmation data from the first processing entity to the third processing entity 
in addition to the other limitations of claim 1 . The Office Action indicates that it is inherent in 
that the first processing entity, which is allegedly a web browser and a third processing entity, 
which is allegedly the JAR file, would somehow require that the web browser must indicate the 
web browser status to the JAR file. However, this appears to be opposite of what the claim 
requires and also is consistent with the cited reference. The claim requires that update 
confirmation data be provided from the first processing entity, such as a computer with a web 
browser, to a third processing entity such as a server that provides the updated web certificates or 
other software. The JAR file in the SmartUpdate reference is merely a file containing, among 
other things, the software to be updated. There is no discussion or need for that JAR file to be 
updated by the web server. To the contrary, it is the JAR file that is used to update the software 
on the computer that contains the web browser as described in the SmartUpdate installation 
reference. Accordingly, this claim is believed to be in condition for allowance. 
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As to claim 4, Applicant again notes, respectfully, that the method requires providing 
update complete data for the second processing entity, namely the processing entity that detects a 
need to update data for the first processing entity, by way of the first processing entity. . 

As to claim 5, this claim is also believed to be allowable for the reasons set forth above 
v^th respect to claim 4. Hence, the update complete data which is provided under control of the 
third processing entity, must be provided by way of the first processing entity. As such this 
relaying of the update complete data as required by the claim is not taught or suggested by the 
cited reference. As admitted in the final Office Action, the second entity is alleged to know that 
an update is complete and therefore able to provide web access to the first entity because the 
updated software is provided from the third entity to the first. There is no teaching or suggestion 
of relaying an update complete cookie or other information from the third processor to the first 
and subsequently fi"om the first processor to the second as required by the claim. Accordingly, 
this claim is also in condition for allowance. 

As to claim 8, this claim requires, among other things, that automatically directing of 
communication is done based on update confirmation data. The Office Action indicates it would 
be inherent. However, the Office Action appears to be using different definitions of first and 
second processing entities. In any event, Applicant respectfiilly notes that "update confirmation 
data" is different from "update complete data" as set forth in Applicant's specification. As such, 
a first processing unit must generate update confirmation data indicating that confirmation data 
is sent from the first processing entity to the third processing entity (see, for example, page 8, 
lines 17-19 of Applicant's specification). Applicant also respectfiilly submits that this claim is 
also allowable for the reasons set forth with respect to claim 1 . 
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As to claims 9 and 10, Applicant respectfully notes that these claims include additional 
novel and nonobvious subject matter and are therefore also allowable. 

As to claim 12, Applicant respectfully reasserts the relevant remarks made above with 
respect to claim 1 . 

As to claim 13, Applicant respectfully reasserts the relevant remarks made above with 
respect to claim 10. 

As to claims 15-17 and 20-21, Applicant respectfully reasserts the relevant remarks made 
above with respect to claims 2-5 and 8-10. 

Claims 6, 7, 11, 18, 19, 22 and 27 stand rejected under 35 U.S.C. §103(a) as being 
unpatentable over the "SmartUpdate" reference and in further view of U.S. Patent No. 6,209,093 
(Venkatesan et al). The Venkatesan reference is directed to a technique for producing a 
privately authenticatable product copy indicia and for authenticating such indicia. For example, 
the indicia may be the access code attached to a cover of a CD ROM and during subsequent user 
installation of a copy to a computer, the user enters the indicia when prompted by the installation 
program, which in turn privately authenticates a signature contained in the indicia in order to 
continue or prematurely terminate the installation. The indicia is tumed into an authentic 
signature based on a public key crypto system. A third key is used in addition to conventional 
two public key crypto systems to give a unique product copy indicia. 

As to claim 6, this claim requires, among other things, the step of detecting the need to 
update data for the first processing entity requires determining whether a connection request 
between the first and second processing entity includes the cookie associated with the second 
processing entity. The Office Action cites Venkatesan for teaching that cookies are used to 
communicate between two entities and that cookies can concern update information. However, 
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Applicant respectfully notes that the Office Action appears to be reading additional disclosure 
into the cited reference. The cited .portion of the reference, namely, column 14, line 41 to 
colunm 15, line 6, indicates that the cookie referred to therein is merely a representation of the 
installation number such as the indicia that contains the authentic signature so that the client's 
computer contains the indicia. The indicia is not update information. Moreover, Applicant's 
claim requires that the system detects whether an update is necessary based on whether a cookie 
is included in the connection request when the cookie is , associated with the second processing 
entity. The indicia in Venkatesan is also not used to determine whether to update data. Such a 
method is not taught or suggested by the cited references and accordingly, this claim is also 
believed to be in condition for allowance. 

As to claim 7, this claim requires, among other limitations, that the data being updated is 
certificate data and also requires determining whether a certificate update should occur based on 
whether cookies have been received by the first processing entity from both the second and third 
processing entities. As such, cookies must be placed by the second and third processing entities 
and analyzed by the first processing entity to determine whether a certificate update should 
occur. Applicant respectfully reasserts the relevant remarks made above with respect to the 
Venkatesan reference and further notes that Venkatesan and the SmartUpdate reference are silent 
as to certificate update techniques as claimed and are also silent as to utilizing cookies from both 
the second and third processing entities as detected by the first processing entity as claimed. As 
such, Applicant respectfully submits that this claim is also in condition for allowance. 

As to claim 11, this claim requires directing the update complete data to the second 
processing entity by using a redirect command back to the first processing entity as initiates by 
the third processing entity and in addition, sending a response to the update complete data, a 
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cookie from the second processing entity to the first processing entity to confirm acceptance of 
the update. Applicant respectfully reasserts the relevant remarks made above v^th respect to the 
Venkatesan and also notes that there is no teaching or suggestion to combine the references. 
Moreover, even in combining the references, there is no teaching or suggestion of sending a 
cookie from the second processing unit to the first processing unit to confirm that acceptance of 
the update nor in providing updated complete data is done imder the control of the third 
processing entity as claimed. Accordingly, this claim is also believed to be in condition for 
allowance. As previously noted, the SmartUpdate developer reference does not appear to 
provide any disclosure as to any closed loop system. 

As to claims 18, 19 and 22, Applicant respectfully reasserts the relevant remarks made 
above with respect to claims 6, 7 and 11. 

With respect to claim 27, Applicant respectfully reasserts the relevant remarks made 
above with respect to claims 6 and 7. 

Accordingly, Applicant respectfully submits that the claims are in condition for 
allowance, and that an early Notice of Allowance be issued in this application. The Examiner is 
invited to contact the below-listed attorney if the Examiner believes that a telephone conference 
will advance the prosecution of this application. 



VEDDER, PRICE, KAUFMAN & KAMMHOLZ 
222 N. LaSalle Street 
Chicago, IL 60601 
(312) 609-7599 
FAX: (312) 609-5005 



Respectfully submitted. 



Date: June 9, 2003 




Registration No 34,414 
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